Hi @Lordworms -- thank you for this PR

I played around with it a bit locally and something still doesn't seem right

Specifically, postgres will treat \1 like a literal string while this PR still tries to escape it...

postgres=# select '\1';
 ?column?
----------
 \1
(1 row)

But when I try in this PR:

select 'DataFusion CLI v45.0.0
> select '\';
+-----------+
| Utf8("\") |
+-----------+
| \         |
+-----------+
1 row(s) fetched.
Elapsed 0.013 seconds.

> select '\1';  🤔 Invalid statement: Execution error: Invalid escape sequence: \1

I think this is correct, because postgresql treats line breaks, such as \t \0, as plain text, but in the original design of DataFusion, \t, \0 should be escaped, so for \1, since it cannot be escaped, an error will be thrown. I think the original purpose of this issue should be to fix single or multiple backslashes. I am not sure whether we should treat all input as plain text like postgresql. 🤔

I think this is correct, because postgresql treats line breaks, such as \t \0, as plain text, but in the original design of DataFusion, \t, \0 should be escaped, so for \1, since it cannot be escaped, an error will be thrown. I think the original purpose of this issue should be to fix single or multiple backslashes. I am not sure whether we should treat all input as plain text like postgresql.

I think you are right that this is the core question: "should datafusion-cli be doing any escaping / unescaping itself?"

If we want to behave like sqllogictest / postgres I think the answer is no. The escaping should happen with the sql supported syntax such as b'...' type literals

Here is a proposed change to this PR that I think fixes the bug by removing unescaping in datafusion-cli:

• Remove all cli unescaping Lordworms/arrow-datafusion#3

I am not sure what I think about this to be honest.

I think you are right that this is the core question: "should datafusion-cli be doing any escaping / unescaping itself?"

no, the CLI should not do thos

If we want to behave like sqllogictest / postgres I think the answer is no. The escaping should happen with the sql supported syntax such as b'...' type literals

yes, this should happen during/after SQL AST is built

in particular, there could be different kind of string literals: such that treat \ as start of an escape sequence, and such that treat \ as just a single backslash character